【レポート】AWS Summit Tokyo 2017：[ソニーモバイルコミュニケーションズ] スマートホームシステムの開発 〜AWS を活用した新規サービスの立ち上げ〜 #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『[ソニーモバイルコミュニケーションズ] スマートホームシステムの開発 〜AWS を活用した新規サービスの立ち上げ〜』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通り。

セッションレポート

• ソフトとハードの進化が進んでいる => IoTの世界が実現しつつある
  • ありとあらゆるデバイスが繋がる
• 新規サービスの共通課題
  • サービスの受容性が分からない => 契約者数の予測が難しい: 初期投資にどれだけかければいいかわからない
  • PDCAのサイクルを早く回す
  • AWSのサービスを利用する
• スマートホームシステムを開発において直面した様々な課題
• その課題をAWSのサービスを利用した解決方法

スマートホームシステム

• 家庭内デバイスを接続してデータ収集
• データ解析により家庭内の状況を把握する
• 家にはHubが置かれる。Hubを通して制御、Hubからデータを送信。そのコントロールをスマホで行う
• スマホの最大の特徴はセキュリティ。家族以外は情報が見られない。

アカウント管理・認証

• スマホからデバイスのデータ照会を安全に行う
  • ユーザの追加・削除
  • アクセストークンを使った認証
  • パスワード変更、Eーmailアドレス変更
• オープンソースを使うと開発/ 運用コストが課題
• Amazon Cognito User Poolを利用する
  • 有料のサービスなので自前のアカウント管理が必要
  • 5万人まで無料 => 5万人を超えるくらいで儲かりだすので、儲からなければ無料でやめられる
  • SMS認証確認などの機能
  • 情報はAuroraにいれて、User Poolはemailのみ利用

使い方

• IDとパスをCognitoに渡してトークンを受ける
• トークンを使ってAPIを呼び出し => API Gateway
• CognitoとLambdaでトークン検証
• OKであればAuroraからデータを取得

ユーザ追加

• 招待する(メール)
• Auroraに仮登録
• アカウント追加リクエストをCognitoに行う
• 確認コードを招待者にメールで送る
• 確認コードを送信（パスワード含む） => API Gateway
• 確認コードでアカウントを有効化するようCognitoにリクエスト
• Auroraを本登録に更新

User Poolの制限

• サインアップ確認コードの有効期限は24時間
  • 確認コードの再送する仕組みは必須
• 確認コードの有効期限をチェックするAPIはない
  • 実際に有効化してみないとわからない
• トークンの有効期限は1時間
• リフレッシュトークンは1-3650日（10年）まで指定可能（デフォルト30日)

デバイス認証

• AWS IoTを使う
  • セキュリティ: 証明書を発行できる、ポリシー
  • 計量な通信
  • ルール処理
  • デバイスの状態をShadowで管理
• 全てのデバイスに対応したIoT Thingsを作成、証明書を発行して全てのデバイスに埋め込む
• デバイスごとにIoT TopicとShadowを用意
• デバイスUUIDに紐付けてTopicとShadowにアクセスするように制限をポリシーを個別に記述。

デバイスとの双方向通信

• AWS IoTのTopicを使う
  • Topicは論理通信チャネル
  • IoT Topicを通してデバイスとメッセージの送受信を行う
• 全てのデバイスにTopic名を振っている(fromDevice, toDeviceなど)
• Ruleを使ってあるTopicからメッセージが来た時に動かす

SELECT * FROM 'devices/+/fromDevice/temperature'

• AWS IoT Topic QoS
  • QoS 0: 多くても1回送る。定期的にデータを送信し、多少のデータ欠損が問題にならない場合に使用
  • QoS 1: ドア開閉など逃してはいけないものに使用。
• Message Brokerの制限
  • アイドルが30分続くと接続が切れる
  • Keep-Aliveの設定をMQTT CONNECT時に5-1200秒まで指定
  • サーバー側はKeep-Aliveの1.5倍の時間以内に通信がない場合は接続を切る
• Pingメッセージを投げる
  • Pingも課金対象なので設定が短いとほぼPingになってしまう。
• Brokerからの切断以外にNATのセッションタイムアウトなどで切断されることもある
• 切れることを想定した実装が必要
• Publishに失敗した場合は再接続を行う
• 適切な間隔でKeep-Aliveを送信する

データ同期

• エッジコンピューティング
• Hub側で処理を行うことも昨今は重要
• AWSでいうGreengrass
• クラウド相当の情報をHubにも持つ
  • データの同期が重要
  • AWS IoT Shadowを使う
  • desired: 送られた情報 reported: 現在の姿 delta: 差分
  • 更新したらreportedでShadowが同期された事を通知
• 制限
  • 最大8kb
  • 変更時は3箇所あるので制限を超えることがある
  • 1つのデバイスで複数のShadowを利用することで解決
  • IoT Policyで書いてあげれば（ワイルドカードを使う)

  xxx/$aws/things/1000*/shadow/get

  shadowはthings/1000-1、のように書く

• 更新頻度が高いものに引っ張られるので分けることで頻度をさげる

まとめ

• 認証: Amazon Cognito User Pool
• デバイス認証: AWS IoT Policy AWS IoT Ceretificate
• 双方向通信: AWS IoT Topic, AWS IoT Rule
• データ同期: AWS IoT Shadow

まとめ

実際のスマートホームシステムの構築に使われたアーキテクチャを細かくご紹介していました。制限などに苦しめられながらも編み出したTipsは説得力がありました。これはすぐにでも使えるのではないでしょうか。